💭 These variables are applicable to all components in the orchestration cluster so I think we need to find a central home for these. As per @megglos suggestion I wonder if we can create a new area for the Core components?

It may be that its more important to just get this in place regardless and then adjust as we go, happy to align off PR.

Followed up on the related issue, but I think ideally we move forward with this iteration, and then make additional Core-related changes in subsequent PRs: https://github.com/camunda/documentation-team/issues/465#issuecomment-2701824081

In favor of having this as a first increment too.

💭 How do you feel about positioning this one as Management cluster Identity?

I would love to have a simple name for this, but right now we use "Web Modeler and Console" throughout the docs. For consistency - and to make it easier to update when/if this gets changed - I'd like to have it match for now.

Do you know if we need to state anything about Optimize explicitly? In the current 8.8 glossary definition of Orchestration core, we include Optimize but don't mention it here at all.

I think that Glossary needs updating after this decision https://camunda.slack.com/archives/C01H4NG9XDY/p1740070705216559 where from my understanding Optimize is not considered part of the core orchestration cluster but a separate component.

can you confirm @RomanJRW @felix-mueller @romansmirnov ?

Yes, this would be true.

The kick-off for Optimize in a dedicated app happened earlier this week. One of the defined action items was for the DRI (@buccarel) to reach out to the Docs team and specify what docs changes need as a result of this decision. This needs a more holistic approach than just tweaks imo

🔧 I'm not sure if it should be noted here or not but the admin role is assigned to all users who are set in the camunda.security.initialization.users list, long term we'd want to refine that IMO but for now thats the functionality

👍🏻 this is a great point to note down, in the future we will look to make the application more defensive during start up but its super important to note this otherwise you can get into a broken state :)

💭 I'm still wondering if this is the right wording but I don't feel strongly enough that we should block the merging. Identity is responsible really for authorization and for managing the assignments to different entities i.e. groups.

The authentication is handled via Spring in the basic setup or via Spring + the provider in cases of OIDC, we do have a new authentication layer/module but its not really exposed.

🔧 effectively Identity is part of the Camunda 8 application, I would thus keep this statement general with regards to Camunda 8 as spring boot application.

🔧 the config applies also to identity itself too,

❌ this is only true for c8run, for helm we default to a secured setup and both are enabled, as the into mentions both distributions, let's label this guide as c8run specific?

❓ what is the default config we want to refer to here? Because this differs by distribution, whether it's c8run or helm, based on the second tab it seems helm? I can then provide the actual defaults next. Some like SPRING_PROFILES_ACTIVE are also not relevant then as the user can't control them.

I see in installation we refer to this as reference from a c8run perspective, I woudl thus suggest to have tabs by distribution c8run and helm. I would omit the ENV variable tab and instead extend the spring boot note by the fact that all properties can be provided as environment variables too, like we do in other places of the docs like here https://docs.camunda.io/docs/next/self-managed/zeebe-deployment/configuration/environment-variables/#environment-variables-for-configuration

Ideally I think this guide should reflect Helm (and other production-ready distributions when ready) and not C8Run at all, as C8Run is unique, not for production, and its configuration requirements are largely handled on its own page. I assume that other production-ready distributions, when available, would reflect the same defaults as Helm?

We've historically had difficulty with users converting from Helm config to environment variables, and the docs team has discussed listing them out separately as we can - @akeller do you have any input here? My thinking was to start having this available for Docker and other distributions down the line, to prevent our docs from being as Helm-biased a they are now.

(Edit: Recognizing that Helm isn't ready for prod, either - but it will be!)

My current understanding is C8Run is for onboarding and non-production use cases to get up and running as quickly as possible (and maybe even, ideally, with no configuration?). Since we prioritize the Java Spring dev during onboarding, leading with the Spring configuration makes sense.

Once we start talking about production distributions, things are a bit unclear to me - what's our happy path or recommendation when it comes to config? Default config feels like a PM decision and I would defer to @FarkasRabai and/or @theburi.

I do think we need to be super explicit about Helm config vs. environment variables vs. properties and not expect our users to do the mapping themselves and add _ or . appropriately. We can't just say "follow this pattern" and document the configuration fully in only one way.

🤞 hope this helps. LMK if there if anything else I can clarify.

❌ you would need to use the --config flag of c8run to make use of an own config, see https://github.com/camunda/camunda-docs/pull/5145/files#diff-5f8b726fad04379e6db620802a56d8916fd1fb90956429487f4b16d80b88afcfR133

❓ what is the default installation, reading further it seems c8run?

🔧 similar to the configuration page, I would not duplicate config for env var setups, given this conversion is a spring boot feature we can refer to generally.

🔧 this duplicates pending changes by #5145 shall we link from one to the other instead?

Would this differ at all if we look at this guide from a Helm default perspective? Otherwise the C8Run guide can point here, but that can be updated separately.

🔧 we should indicate these are different identity components indeed

I've tried to clarify this further in the latest update! Once there is a place in the docs for Orchestration cluster docs vs Everything else docs, this page will mostly be able to go away, and I hope this distinction will feel much more separate.